Telecommunications network providers must manage large volumes of data. For example, a telecommunications network provider may store millions of records of customer data on database server networks that are heavily accessed and frequently updated. This customer data can include customer identifications, passwords, addresses, preferences, etc. which must be accessible by a variety of different users. A common method for managing such data includes creating directory listings using the Lightweight Directory Access Protocol (LDAP). LDAP is a TCP/IP compliant protocol that provides for the quick access and update of directory listings. LDAP-supported systems have been implemented in a variety of contexts such as web browsers and email programs.
These LDAP directory listings are stored on database server networks that typically include multiple server tiers, each tier having one or more servers. For example, a server network can include a master server tier, a HUB server tier, and a proxy server tier, among other tiers. Each server tier is located at different proximities from a user. For example, a proxy server may be located in close proximity to a user whereas a higher level master server may be located further from the user. Generally, the closer the data is stored to a user, the quicker the response to a user query. Thus, in an effort to avoid delays, data that is frequently accessed by a user is typically stored on a server in close proximity to the user. For example, data associated with common user queries can be stored on a proxy server near the user.
When a modification to the data is made by a client application, the data is typically updated throughout the server network depending upon the particular characteristics of the update. A typical update involves providing the modification to a master server and then propagating the modification throughout the server network. The master server serves as a gatekeeper for data updates ensuring data integrity. The modification also referred to herein as an update can then be sent to other servers as required. For example, when a user creates a new password for use on the communications network then this change is updated on the server network. If the user has multiple access points to the network the new password must be made available to servers serving those access points so that the user can login from all the access points. For example, the new password can be sent to a master server associated with the user along with an update request requesting that the server network be updated with the new password. The master server receives the user's new password and update request and updates the network by propagating the new password throughout the server network as required. This propagation of this modification or data update to other servers is often referred to as “replication.” By replicating data from the master server to other servers, the modification is “pushed” to server tiers closer to the user, thereby enabling the network to provide the user with a quick and accurate response from multiple server locations. Thus, a modification of the network triggers an update request requesting that the server network be updated to reflect the modification. This update request may be referred to as a replication request herein.
This update or replication process allows other servers in addition to a master server to respond to user requests. To maintain control over the replication process and ensure data integrity, LDAP servers are typically arranged in a master-slave arrangement. Replication requests are thus first sent to the master server and then updates sent to server destinations or “replicated” as required.
As discussed above, in order to update data throughout the server network, data is replicated across various server tiers so that multiple servers can provide up-to-date data. Problems can arise however when data is not efficiently updated at the master server or efficiently replicated to other servers. Under prior art LDAP schemes updates are processed on a first-in-first-out basis without regard to business decisions or priorities. But many of these updates do not require immediate replication throughout the server network. For example, a modification changing a user's mailing address will not immediately affect a user's use of the telecommunications system. However, the change of a password can significantly affect a user's ability to access the network if it is not immediately replicated. In addition, large numbers of replication requests are frequently stored as batch update requests. These batch requests can require a large amount of resources to process. Under the present first-in-first-out approach if a large batch file is received at an LDAP server prior to the afore-mentioned password update request, the batch request would be processed first, thereby resulting in the delay of the replication of the password request. This delay is undesirable as it can affect the user's ability to access the network. Thus, there are a variety of update requests which can be received by the master for which immediate replication throughout the server network is desirable. Thus, problems can arise with the prior art first-in-first-out replication method. For example, large batch files of low priority may be received prior to more important requests which will be delayed as the system processes or replicates the earlier batch files.
Thus, it is desirable to have an improved method of updating server networks and more particularly processing update or replication requests and replicating data on a server network that overcomes these difficulties and allows high priority requests to be processed in a more timely manner.